home *** CD-ROM | disk | FTP | other *** search
/ InfoMagic Standards 1994 January / InfoMagic Standards - January 1994.iso / ccitt / 1988 / troff / 6_1_11.tro < prev    next >
Text File  |  1991-12-13  |  30KB  |  1,383 lines
  1. .rs
  2. .\" Troff code generated by TPS Convert from ITU Original Files
  3. .\"                 Not Copyright ( c) 1991 
  4. .\"
  5. .\" Assumes tbl, eqn, MS macros, and lots of luck.
  6. .TA 1c 2c 3c 4c 5c 6c 7c 8c
  7. .ds CH
  8. .ds CF
  9. .EQ
  10. delim @@
  11. .EN
  12. .nr LL 40.5P
  13. .nr ll 40.5P
  14. .nr HM 3P
  15. .nr FM 6P
  16. .nr PO 4P
  17. .nr PD 9p
  18. .po 4P
  19.  
  20. .rs
  21. \v | 5i'
  22. .LP
  23. \fBMONTAGE:\ FIN DE LA RECOMMANDATION Q.82 en\(hyt\* | te de cette page\fR 
  24. .sp 2P
  25. .LP
  26. \v'37P'
  27. \fBRecommendation\ Q.83\fR 
  28. .RT
  29. .sp 2P
  30. .sp 1P
  31. .ce 1000
  32. \fBCALL COMPLETION SUPPLEMENTARY SERVICES\fR 
  33. .EF '%    Fascicle\ VI.1\ \(em\ Rec.\ Q.83''
  34. .OF '''Fascicle\ VI.1\ \(em\ Rec.\ Q.83    %'
  35. .ce 0
  36. .sp 1P
  37. .LP
  38. \fR \fB1\fR     \fBCall waiting\fR 
  39. .sp 1P
  40. .RT
  41. .sp 1P
  42. .LP
  43. 1.1
  44.     \fIGeneral\fR 
  45. .sp 9p
  46. .RT
  47. .PP
  48. This Recommendation provides information on the functions in ISDN entities 
  49. and the information flows between the entities which are required to provide 
  50. the call waiting supplementary service. 
  51. .PP
  52. The \fBcall waiting supplementary service\fR will permit a subscriber to 
  53. be notified of an incoming call (as per basic call procedures) with an 
  54. indication that no interface information channel is available.
  55. .PP
  56. The user then has the choice of accepting, rejecting or ignoring the waiting 
  57. call (as per basic call procedures). 
  58. .bp
  59. .RT
  60. .sp 2P
  61. .LP
  62. 1.2
  63.     \fIDescription\fR 
  64. .sp 1P
  65. .RT
  66. .sp 1P
  67. .LP
  68. 1.2.1
  69.     \fIGeneral description\fR 
  70. .sp 9p
  71. .RT
  72. .PP
  73. The ISDN call waiting service allows notification to subscriber\ B of the 
  74. incoming call to be out\(hyof\(hyband and this is the assumed case for 
  75. this 
  76. definition. In addition, as a service provider option audible in\(hyband
  77. indications may be provided.
  78. .PP
  79. Where this option is provided, the application of in\(hyband indications, 
  80. in relation to particular call types and channels, is for further study. 
  81. Where applied, tones should be in accordance with Recommendation\ E.180. 
  82. .PP
  83. The maximum number of calls that can be handled (e.g. active, held,
  84. alerting, waiting) for each ISDN number on a given interface is specified at
  85. subscription time.
  86. .RT
  87. .sp 1P
  88. .LP
  89. 1.2.2
  90.     \fIQualifications on the applicability to telecommunication\fR 
  91. \fIservices\fR 
  92. .sp 9p
  93. .RT
  94. .PP
  95. This supplementary service is considered meaningful when applied to the 
  96. telephony teleservice, speech and 3.1\ kHz audio bearer services. 
  97. Furthermore, it may also be meaningful when applied to other services.
  98. .RT
  99. .sp 1P
  100. .LP
  101. 1.3
  102.     \fIDerivation of the functional model for call waiting service\fR 
  103. .sp 9p
  104. .RT
  105. .PP
  106. The model used for illustrating the call waiting supplementary
  107. service procedures is given below:
  108. .RT
  109. .LP
  110. .rs
  111. .sp 10P
  112. .ad r
  113. \fBFIGURE, p.  \fR 
  114. .sp 1P
  115. .RT
  116. .ad b
  117. .RT
  118. .PP
  119. CCA is the functional entity that serves the user and is
  120. responsible for initiating functional requests and interacting with the
  121. network. CC is the functional entity within the network that cooperates with
  122. its peers to provide the services requested by CCA.
  123. .PP
  124. r\d1\uand r\d2\uare relationships between functional entities wherein information 
  125. flows occur in order to process call attempts on service 
  126. requests.
  127. .RT
  128. .sp 1P
  129. .LP
  130. 1.4
  131.     \fIInformation flow diagrams\fR 
  132. .sp 9p
  133. .RT
  134. .PP
  135. This paragraph contains the information flow diagram for the
  136. successful sequences of call waiting.
  137. .PP
  138. The following flow diagrams are identified:
  139. .RT
  140. .LP
  141.     \(em
  142.     Figure\ 1\(hy1/Q.83:
  143.     call waiting notification: case\ 1;
  144. .LP
  145.     \(em
  146.     Figure\ 1\(hy2/Q.83:
  147.     call waiting notification: case\ 2;
  148. .LP
  149.     \(em
  150.     Figure\ 1\(hy3/Q.83:
  151.     call waiting notification: case\ 3;
  152. .LP
  153.     \(em
  154.     Figure\ 1\(hy4/Q.83:
  155.     call waiting acceptance by clearing the   A\ call: case\ 1;
  156. .LP
  157.     \(em
  158.     Figure 1\(hy5/Q.83:
  159.     call waiting acceptance by clearing the   A\ call: case\ 2;
  160. .LP
  161.     \(em
  162.     Figure 1\(hy6/Q.83:
  163.     call waiting acceptance by holding the
  164. A\ call: case\ 1;
  165. .LP
  166.     \(em
  167.     Figure 1\(hy7/Q.83:
  168.     call waiting acceptance by holding the
  169. A\ call: case\ 2;
  170. .LP
  171.     \(em
  172.     Figure 1\(hy8/Q.83:
  173.     call waiting rejection;
  174. .LP
  175.     \(em
  176.     Figure 1\(hy9/Q.83:
  177.     call waiting cancellation.
  178. .bp
  179. .sp 1P
  180. .LP
  181. 1.4.1
  182.     \fICall waiting terminology\fR 
  183. .sp 9p
  184. .RT
  185. .PP
  186. Throughout the stage\ 2 description the following terminology will   be used:
  187. .RT
  188. .LP
  189.     i)
  190.      Subscriber B: This is the subscriber who is provided by the network with 
  191. call waiting service on a particular interface. 
  192. .LP
  193.     ii)
  194.     User at B: This is the one user who reacts to the call
  195. waiting at B.
  196. .LP
  197.     iii)
  198.     User C: This is the user who has originated a call to B
  199. which causes the call waiting service to be invoked.
  200. .LP
  201.     iv)
  202.      One user at A: This represents a user who is engaged in a call with a 
  203. user at B (this call can be in any state). 
  204. .LP
  205.     v)
  206.      Information channel control: A terminal that has information channel 
  207. control is active on a call, is alerting for an incoming call, has an outgoing 
  208. call in a state following or including the outgoing call proceeding 
  209. state, or has a call on hold with reservation.
  210. .sp 1P
  211. .LP
  212. 1.4.2
  213.     \fICall waiting procedures with successful outcome\fR 
  214. .sp 9p
  215. .RT
  216. .PP
  217. The call waiting procedures with successful outcome are hereafter described 
  218. by means of generic information flow diagrams. 
  219. .RT
  220. .sp 1P
  221. .LP
  222. 1.4.2.1
  223.     \fICall waiting notification\fR 
  224. .sp 9p
  225. .RT
  226. .PP
  227. The call waiting notification procedures are given in
  228. Figures\ 1\(hy1/Q.83 to 1\(hy3/Q.83.
  229. .PP
  230. Two categories are identified:
  231. .RT
  232. .LP
  233.     i)
  234.     Figures\ 1\(hy1/Q.83 and 1\(hy2/Q.83 describe the case where the
  235. served user is notified of an incoming call and the network requires an
  236. interface channel to his user access and it has detected that all information 
  237. channels are in use (no information channel available). 
  238. .LP
  239.     ii)
  240.      Figure\ 1\(hy3/Q.83 describes the case where the served user is notified 
  241. of an incoming call and the network requires an interface channel to his 
  242. user access and it has detected that an existing free information channel, 
  243. which is the only compatible terminal, is in the busy condition (information 
  244. channel available).
  245. .PP
  246. The following procedures are valid for call waiting with no
  247. information channel available.
  248. .PP
  249. When an incoming call from a user\ C arrives at the functional entity controlling 
  250. the access at B and encounters the channel's busy condition and the network 
  251. determined user busy conditions do not result, then the call shall be offered 
  252. to B by means of the Setup procedure with the \*Qno information channel\*U 
  253. indicated. 
  254. .PP
  255. The following actions will be taken by the terminals connected to the user\ 
  256. B access: 
  257. .RT
  258. .LP
  259.     i)
  260.     Incompatible terminals will not react.
  261. .LP
  262.     ii)
  263.      Terminals not presently controlling the information channel that are 
  264. compatible with the incoming call will respond by initiating the 
  265. release procedure indicating a no information circuit/channel available
  266. condition.
  267. .LP
  268.     iii)
  269.     Terminals presently controlling the information channel
  270. that do not support the call waiting service and are compatible with the
  271. incoming call will respond either by initiating the release procedure
  272. indicating a user busy condition or by acting as incompatible terminals 
  273. (e.g. no reaction). 
  274. .LP
  275.     iv)
  276.     Terminals presently controlling the information channel
  277. that support the call waiting service and that are compatible with the 
  278. incoming call will respond by initiating the call progress (reporting) 
  279. procedure and 
  280. will give a local alert to the human user by giving an audible and/or visual
  281. (in\(hyband) indication.
  282. .PP
  283. When a positive response is received from the terminals at B
  284. within the normal basic call period, that (those) user(s) is (are) being
  285. informed about the incoming call, then the calling user at C will be given 
  286. an indication that the called user(s) is (are) being informed. This will 
  287. be 
  288. performed by the network at the B side by sending of the ringing tone; some
  289. networks may instead generate a special call waiting tone, provided the 
  290. bearer capability is either speech or audio 3.1\ kHz. In addition, optionally, 
  291. a call waiting out of band indication may be sent to the\ C user. 
  292. .PP
  293. \fICase\ 1\fR : Both B Channels busy, one terminal controlling a B Channel 
  294. supports call waiting. 
  295. .bp
  296. .PP
  297. Figure\ 1\(hy1/Q.83 shows the generic information flow diagram for call
  298. waiting notification when the incoming call from user\ C is delivered at the
  299. user\ B access by broadcast data link without available information channels.
  300. .PP
  301. The following user B access terminals are assumed:
  302. .RT
  303. .LP
  304.     \(em
  305.      TE1: Being a compatible terminal not supporting call waiting occupying 
  306. channel\ B\d1\uand having a call reference CR1. This terminal is 
  307. assumed to be located in FE6.
  308. .LP
  309.     \(em
  310.     TE2: Being a compatible terminal not presently controlling
  311. the information channel. This terminal is assumed to be located in FE6`.
  312. .LP
  313.     \(em
  314.     TE3: Being a compatible terminal supporting call waiting,
  315. occupying channel\ B\d2\uand having a call reference CR2. This terminal is
  316. assumed to be located in FE6".
  317. .PP
  318. The new incoming call from C is assumed to have a call reference   CR3.
  319. .PP
  320. \fICase 2\fR :\ Both B Channels busy, both terminals controlling the B
  321. Channels support call waiting.
  322. .PP
  323. Figure\ 1\(hy2B/FQ.83 shows the generic information flow diagram for call
  324. waiting notification when the incoming call from user\ C is delivered at the
  325. user\ B access by broadcast data link without available information channels.
  326. .PP
  327. The following user B access terminals are assumed.
  328. .RT
  329. .LP
  330.     \(em
  331.     TE1: Being a compatible terminal supporting call waiting
  332. occupying channel\ B\d1\uand having a call reference CR1. This terminal is
  333. assumed to be located in FE6.
  334. .LP
  335.     \(em
  336.     TE2: Being a compatible terminal not presently
  337. controlling the information channel. This terminal is assumed to be located 
  338. in FE6`. 
  339. .LP
  340.     \(em
  341.     TE3: Being a compatible terminal supporting call
  342. waiting, occupying channel B\d2\uand having a call reference CR2. This 
  343. terminal is assumed to be located in FE6". 
  344. .PP
  345. The new incoming call from C is assumed to have a call reference   CR3.
  346. .PP
  347. \fICase 3\fR : One B Channel busy, the terminal controlling the busy B
  348. Channel supporting call waiting.
  349. .PP
  350. Figure\ 1\(hy3/Q.83 shows the generic information flow diagram for call
  351. waiting notification when the incoming call from user\ C is delivered at the
  352. user\ B access by broadcast data link with an available information channel, 
  353. but the only compatible terminal is presently controlling an information 
  354. channel. 
  355. .PP
  356. If the thus compatible terminal has call waiting facilities available, 
  357. it alerts its user (audible or visible indication) and notifies the network 
  358. (REPORT). The user then can decide whether to accept the waiting call or
  359. not.
  360. .RT
  361. .sp 1P
  362. .LP
  363. 1.4.2.2
  364.     \fICall waiting acceptance\fR 
  365. .sp 9p
  366. .RT
  367. .PP
  368. If a user at B requests, within a specified period, to connect to the waiting 
  369. call, two procedures may be required by user\ B with regard to the active 
  370. call with a user at\ A. 
  371. .RT
  372. .LP
  373.     i)
  374.      Procedure one will terminate the specified active call with a user at 
  375. A, while the call between a user at C and the user at B is completed in 
  376. the normal manner (see Figures\ 1\(hy4/Q.83 and 1\(hy5/Q.83). 
  377. .LP
  378.     ii)
  379.      Procedure two will place the specified active call with a user at\ A 
  380. into a held state, while the call between a user at\ C and the user 
  381. at\ B will be completed in the normal manner. The previously active call 
  382. between a user at\ A and the user at\ B is put into the held state. From 
  383. this state other supplementary services, for example, three party service 
  384. may be used (see 
  385. Figures\ 1\(hy6/Q.83 and 1\(hy7/Q.83).
  386. .LP
  387.      This acceptance provokes the initiation of a Hold sequence by the terminal 
  388. to the network. The network will hold the previous call between a user 
  389. at A and the user at B, while the waiting call from a user at C will be 
  390. connected by a Setup responseB/Fconfirm sequence.
  391. .LP
  392.      Since more than one terminal controlling the information channels can 
  393. respond positively to a call waiting offering, the network will 
  394. subsequently apply a clear procedure to the remaining terminals having
  395. responded positively after having received the Setup response/confirmation
  396. order.
  397. .bp
  398. .LP
  399. .rs
  400. .sp 47P
  401. .ad r
  402. \fBFigure 1\(hy1/Q.83, p. 2\fR 
  403. .sp 1P
  404. .RT
  405. .ad b
  406. .RT
  407. .LP
  408. .bp
  409. .LP
  410. .rs
  411. .sp 47P
  412. .ad r
  413. \fBFigure 1\(hy2/Q.83, p. 3\fR 
  414. .sp 1P
  415. .RT
  416. .ad b
  417. .RT
  418. .LP
  419. .bp
  420. .LP
  421. .rs
  422. .sp 47P
  423. .ad r
  424. \fBFigure 1\(hy3/Q.83, p. 4\fR 
  425. .sp 1P
  426. .RT
  427. .ad b
  428. .RT
  429. .LP
  430. .bp
  431. .LP
  432. .rs
  433. .sp 47P
  434. .ad r
  435. \fBFigure 1\(hy4/Q.83, p. 5\fR 
  436. .sp 1P
  437. .RT
  438. .ad b
  439. .RT
  440. .LP
  441. .bp
  442. .LP
  443. .rs
  444. .sp 47P
  445. .ad r
  446. \fBFigure 1\(hy5/Q.83, p. 6\fR 
  447. .sp 1P
  448. .RT
  449. .ad b
  450. .RT
  451. .LP
  452. .bp
  453. .LP
  454. .rs
  455. .sp 47P
  456. .ad r
  457. \fBFigure 1\(hy6/Q.83, p. 7\fR 
  458. .sp 1P
  459. .RT
  460. .ad b
  461. .RT
  462. .LP
  463. .bp
  464. .LP
  465. .rs
  466. .sp 47P
  467. .ad r
  468. \fBFigure 1\(hy7/Q.83, p. 8\fR 
  469. .sp 1P
  470. .RT
  471. .ad b
  472. .RT
  473. .LP
  474. .bp
  475. .sp 1P
  476. .LP
  477. 1.4.2.3
  478.     \fICall waiting rejection\fR 
  479. .sp 9p
  480. .RT
  481. .PP
  482. The user at B can also, within the specified period, reject the new incoming 
  483. call from user C. In this case, call clearing procedures (see 
  484. Figure\ 1\(hy8/Q.83) will apply at the basic access interface.
  485. .PP
  486. If the terminals controlling the information channels have initiated the 
  487. Report (alerting) procedures, the network will wait after the reception 
  488. of the first release sequence from a terminal for the possible reaction 
  489. of the 
  490. other terminal. If all the users reject the waiting call, the network shall
  491. initiate the clearing of the call indicating the user determined busy condition 
  492. of the called users to the calling user\ C. 
  493. .RT
  494. .sp 1P
  495. .LP
  496. 1.4.2.4
  497.     \fICall waiting notification ignored\fR 
  498. .sp 9p
  499. .RT
  500. .PP
  501. If the specified period expires without any acceptance from B of
  502. the incoming call, then the network shall inform\ B of this situation and 
  503. also inform\ C that this call cannot be connected. 
  504. .PP
  505. Normal release applies to the call attempt from C by sending an
  506. appropriate clearing indication to the calling user (see Figure\ 1\(hy9/Q.83).
  507. .PP
  508. A rejection of the waiting call by one terminal will not stop the call 
  509. waiting timer, as another terminal may accept the waiting call within the 
  510. specified period.
  511. .RT
  512. .sp 1P
  513. .LP
  514. 1.5
  515.     \fISDL diagrams for functional entities\fR 
  516. .sp 9p
  517. .RT
  518. .PP
  519. This section contains the SDL diagrams for the network function
  520. entity FE5. The entire SDL is a variation of the basic call r\d2\u\(hyr\d1\uCALL 
  521. SENT state. 
  522. .PP
  523. The relationships \*Qr\d1\u\*U and \*Qr\d2\u\*U have been deleted in functional 
  524. entity FE5 between functional entities FE4 (r\d2\u) and FE6 (r\d1\u). 
  525. (See\ \(sc\ 1.3.)
  526. .RT
  527. .sp 1P
  528. .LP
  529. 1.6
  530.     \fIFunctional entity actions\fR 
  531. .sp 9p
  532. .RT
  533. .PP
  534. The functional entity actions are identical to the actions required for 
  535. the circuit mode switched bearer services speech, 3.1\ kHz audio 
  536. unrestricted and alternate speech/unrestricted information transfer.
  537. .RT
  538. .LP
  539. .rs
  540. .sp 25P
  541. .ad r
  542. Blanc
  543. .ad b
  544. .RT
  545. .LP
  546. .bp
  547. .LP
  548. .rs
  549. .sp 47P
  550. .ad r
  551. \fBFigure 1\(hy8/Q.83, p. 9\fR 
  552. .sp 1P
  553. .RT
  554. .ad b
  555. .RT
  556. .LP
  557. .bp
  558. .LP
  559. .rs
  560. .sp 47P
  561. .ad r
  562. \fBFigure 1\(hy9/Q.83, p. 10\fR 
  563. .sp 1P
  564. .RT
  565. .ad b
  566. .RT
  567. .LP
  568. .bp
  569. .LP
  570. .rs
  571. .sp 47P
  572. .ad r
  573. \fBFigure 1\(hy10/Q.83 (feuillet 1 sur 7), p. 11\fR 
  574. .sp 1P
  575. .RT
  576. .ad b
  577. .RT
  578. .LP
  579. .bp
  580. .LP
  581. .rs
  582. .sp 47P
  583. .ad r
  584. \fBFigure 1\(hy10/Q.83 (feuillet 2 sur 7), p. 12\fR 
  585. .sp 1P
  586. .RT
  587. .ad b
  588. .RT
  589. .LP
  590. .bp
  591. .LP
  592. .rs
  593. .sp 47P
  594. .ad r
  595. \fBFigure 1\(hy10/Q.83 (feuillet 3 sur 7), p. 13\fR 
  596. .sp 1P
  597. .RT
  598. .ad b
  599. .RT
  600. .LP
  601. .bp
  602. .LP
  603. .rs
  604. .sp 47P
  605. .ad r
  606. \fBFigure 1\(hy10/Q.83 (feuillet 4 sur 7), p. 14\fR 
  607. .sp 1P
  608. .RT
  609. .ad b
  610. .RT
  611. .LP
  612. .bp
  613. .LP
  614. .rs
  615. .sp 47P
  616. .ad r
  617. \fBFigure 1\(hy10/Q.83 (feuillet 5 sur 7), p. 15\fR 
  618. .sp 1P
  619. .RT
  620. .ad b
  621. .RT
  622. .LP
  623. .bp
  624. .LP
  625. .rs
  626. .sp 47P
  627. .ad r
  628. \fBFigure 1\(hy10/Q.83 (feuillet 6 sur 7), p. 16\fR 
  629. .sp 1P
  630. .RT
  631. .ad b
  632. .RT
  633. .LP
  634. .bp
  635. .LP
  636. .rs
  637. .sp 47P
  638. .ad r
  639. \fBFigure 1\(hy10/Q.83 (feuillet 7 sur 7), p. 17\fR 
  640. .sp 1P
  641. .RT
  642. .ad b
  643. .RT
  644. .LP
  645. .bp
  646. .sp 1P
  647. .LP
  648. 1.7
  649.     \fIAllocation of functional entities to physical locations\fR 
  650. .sp 9p
  651. .RT
  652. .PP
  653. The following allocation of functional entities to physical
  654. locations of the call waiting supplementary service are applicable:
  655. .RT
  656. .LP
  657.     i)
  658.     \fICase\ 1\fR 
  659. .LP
  660.     FE1
  661.     FE3
  662.     FE4
  663.     FE5
  664.     FE6
  665. .LP
  666.     FE2\ <ACCESS>
  667.     FE7\ <NETWORK>
  668.     FE8\ <NETWORK>
  669.     LE\ <ACCESS>
  670.     TE
  671. .LP
  672.     TE
  673.     LE
  674.     TR
  675. .LP
  676.     FE1, FE2 and FE6 are the functional entities which
  677. represent the users of the call waiting supplementary service (e.g. may be
  678. physically located in TE or NT2 equipment). FE1 represents user\ A, FE2 
  679. user\ C and FE6 user\ B. FE6 is the service requesting terminal and FE1 
  680. and FE2 the 
  681. remote terminals.
  682. .LP
  683.     FE3, FE4, FE5, FE7 and FE8 are the functional entities which
  684. represent the network functions.
  685. .LP
  686.      FE5 represents the network access providing exchange, FE4 and FE8 the 
  687. transit exchanges, FE3 and FE7 the remote local exchanges. 
  688. .LP
  689.     ii)
  690.     \fICase 2\fR 
  691. .LP
  692.     FE1
  693.     FE3
  694.     FE4
  695.     FE5
  696.     FE6
  697. .LP
  698.     FE2\ <ACCESS>
  699.     FE7\ <NETWORK>
  700.     FE8\ <ACCESS>
  701.     NT2\ <ACCESS>
  702.     TE
  703. .LP
  704.     TE
  705.     LE
  706.     LE
  707.     (PRA)
  708.     (BA)
  709. .LP
  710.      FE1, FE2, FE5 AND FE6 are the functional entities which represent the 
  711. users of the call waiting supplementary service. FE1 represents user\ A, 
  712. FE2 user\ C.
  713. .LP
  714.     FE6 is the service requesting terminal while FE5 represents the
  715. service providing NT2.
  716. .LP
  717.      FE3, FE4, FE7 and FE8 are the functional entities which represent the 
  718. local network functions. 
  719. .LP
  720.     iii)
  721.     \fICase 3\fR 
  722. .LP
  723.     FE1
  724.     FE3
  725.     FE4
  726.     FE5
  727. .LP
  728.     FE2\ <ACCESS>
  729.     FE7\ <ACCESS>
  730.     FE8\ <NETWORK>
  731.     LE\ <ACCESS>
  732.     FE6
  733. .LP
  734.     TE
  735.     NT2
  736.     LE
  737. .LP
  738.     FE1, FE2, FE3, FE6 and FE7 are the functional entities which
  739. represent the users of the call waiting supplementary service. FE1 and FE3
  740. represent user\ A, FE2 and FE7 represent user\ C while FE6 represents user\ B.
  741. .LP
  742.     FE6 is the service requesting terminal, FE1 and FE2 the remote
  743. terminals and FE3 and FE7 the remote NT2s.
  744. .LP
  745.      FE4, FE5 and FE8 are the functional entities which represent the local 
  746. network functions. 
  747. .LP
  748.     iv)
  749.     \fICase 4\fR 
  750. .LP
  751.     FE1
  752.     FE3
  753.     FE4
  754.     FE5
  755. .LP
  756.     FE2\ <ACCESS>
  757.     FE7\ <NETWORK>
  758.     FE8\ <ACCESS>
  759.     NT2\ <ACCESS>
  760.     FE6
  761. .LP
  762.     NT2
  763.     LE
  764.     LE
  765. .LP
  766.      FE1, FE2, FE5 and FE6 are the functional entities which represent the 
  767. users of the call waiting supplementary service. FE1 represents user\ A, 
  768. FE2 user\ C and FE5 and FE6 user\ B, FE6 being the service requesting terminal.
  769. .LP
  770.     FE5 being the service providing NT2 and FE1 and FE2 the remote
  771. terminals.
  772. .LP
  773.      FE3, FE4, FE7 and FE8 are the functional entities which represent the 
  774. local network functions. 
  775. .LP
  776.     v)
  777.     \fICase 5\fR 
  778. .LP
  779.     FE1
  780.     FE3
  781.     FE4
  782.     FE5
  783. .LP
  784.     FE2\ <ACCESS>
  785.     FE7\ <NETWORK>
  786.     FE8\ <ACCESS>
  787.     TE
  788. .LP
  789.     TE/NT2
  790.     LE
  791. .LP
  792.      FE1, FE2 and FE5 are the functional entities which represent the users 
  793. of the call waiting supplementary service. FE1 represents user\ A, FE2 
  794. user\ C and FE5 and FE6 user\ B, FE5 is as well as the service requesting 
  795. as the service providing terminal while FE1 and FE2 are the remote terminals/NT2s. 
  796. .LP
  797.      FE3, FE4, FE7 and FE8 are the functional entities which represent the 
  798. local network functions. 
  799. .sp 2P
  800. .LP
  801. \fB2\fR     \fBCall hold\fR 
  802. .sp 1P
  803. .RT
  804. .sp 1P
  805. .LP
  806. 2.1
  807.     \fIIntroduction\fR 
  808. .sp 9p
  809. .RT
  810. .PP
  811. References: CCITT Recommendation I.253, \(sc\ 2, Call hold (Stage\ 1)
  812. Service description.
  813. .PP
  814. This paragraph includes treatment of the network options as described in 
  815. the Stage\ 1 service description. Specifically, (1) optional notification 
  816. to the held party indicating that the call has been placed on hold, and 
  817. (2) 
  818. optional notification to the held party that a call has been
  819. retrieved.
  820. .bp
  821. .RT
  822. .sp 1P
  823. .LP
  824. 2.1.1
  825.     \fIDefinition\fR 
  826. .sp 9p
  827. .RT
  828. .PP
  829. The \fBcall hold service\fR allows a user to interrupt
  830. communications on an existing call/connection
  831. .FS
  832. The applicability of the hold service a \*Qcall\*U versus a \*Qconnection\*U 
  833. requires further study. 
  834. .FE
  835. and then
  836. subsequently, if desired, re\(hyestablish communications. A B Channel
  837. .FS
  838. The
  839. applicability of this service definition to other access resources
  840. (e.g.,\ H\(hychannels, logical channels) for other services requires further
  841. study.
  842. .FE
  843. may or may not be reserved after the communication is interrupted to allow 
  844. the origination or possible termination of other calls. Reservation 
  845. must be provided by the service provider as a user option. The Call Hold
  846. service includes the Retrieve operation which re\(hyestablishes communication 
  847. on a B Channel between the served user and the held party. 
  848. .RT
  849. .sp 2P
  850. .LP
  851. 2.2
  852.     \fIDefinition of functional model\fR 
  853. .sp 1P
  854. .RT
  855. .sp 1P
  856. .LP
  857. 2.2.1
  858.     \fIFunctional model description\fR 
  859. .sp 9p
  860. .RT
  861. .LP
  862. .rs
  863. .sp 8P
  864. .ad r
  865. \fBFigure 2\(hy1/Q.83, p.  \fR 
  866. .sp 1P
  867. .RT
  868. .ad b
  869. .RT
  870. .PP
  871. r, along with its subscripts, represents different information
  872. flow relationships between functional entities. FE3 and FE4 are shown as 
  873. dashed circles to represent their optional nature in the context of the 
  874. Call Hold 
  875. Service.
  876. .sp 1P
  877. .LP
  878. 2.2.1.1
  879.     \fIDescription of functional entity 1\fR 
  880. .sp 9p
  881. .RT
  882. .PP
  883. Functional entity 1 supports the following functionality:
  884. .RT
  885. .LP
  886.     1)
  887.     access the service providing capabilities of functional
  888. entity 2 by way of functional service requests (e.g., hold request, retrieve
  889. request);
  890. .LP
  891.     2)
  892.     receive functional indications relating to the call from
  893. functional entity 2 and relay them to the \*Quser\*U of the call (e.g., hold
  894. confirmation, retrieve confirmation).
  895. .sp 1P
  896. .LP
  897. 2.2.1.2
  898.     \fIDescription of functional entity 2\fR 
  899. .sp 9p
  900. .RT
  901. .PP
  902. Functional entity 2 supports the following functionality:
  903. .RT
  904. .LP
  905.     1)
  906.     receive the functional service requests from functional
  907. entity 1 and relay them into the network (e.g., receive the hold request 
  908. from functional entity 1 and relay an optional notification of the held 
  909. call toward user B); 
  910. .LP
  911.     2)
  912.     perform the holding function (functional entity action
  913. 201);
  914. .LP
  915.     3)
  916.     send functional indications relating to the call to
  917. functional entity 1 (e.g., hold confirmation, retrieve confirmation);
  918. .LP
  919.     4)
  920.     reserve an information channel, if reservation is
  921. subscribed to (functional entity action 203);
  922. .LP
  923.     5)
  924.     perform reservation management (functional entity action
  925. 204);
  926. .LP
  927.     6)
  928.     perform the retrieve function (functional entity action
  929. 202).
  930. .bp
  931. .sp 1P
  932. .LP
  933. 2.2.1.3
  934.     \fIDescription of functional entity 3\fR 
  935. .sp 9p
  936. .RT
  937. .PP
  938. Functional entity 3 supports the following functionality:
  939. .RT
  940. .LP
  941.     1)
  942.     receive the optional notification of call hold and the
  943. optional notification of retrieval and relay them toward functional entity\ 4;
  944. .LP
  945.     2)
  946.     identify the call at the FE3/FE4 interface that the
  947. optional notifications apply to (functional entity action 205).
  948. .sp 1P
  949. .LP
  950. 2.2.1.4
  951.     \fIDescription of functional entity 4\fR 
  952. .sp 9p
  953. .RT
  954. .PP
  955. Functional entity 4 supports the following functionality:
  956. .RT
  957. .LP
  958.     1)
  959.     receive the optional notification of call hold and the
  960. optional notification of retrieval and inform (relay them to) user\ B.
  961. .sp 1P
  962. .LP
  963. 2.2.2
  964.     \fIRelationship to basic service\fR 
  965. .sp 9p
  966. .RT
  967. .LP
  968. .rs
  969. .sp 14P
  970. .ad r
  971. \fBFigure 2\(hy2/Q.83, p.  \fR 
  972. .sp 1P
  973. .RT
  974. .ad b
  975. .RT
  976. .PP
  977. The call control agent (CCA) is the functional entity that serves the user 
  978. and is responsible for initiating functional requests and interacting with 
  979. the network. Call control (CC) is performed by functional entities within 
  980. the network to provide the services requested by the CCA. 
  981. .LP
  982. .rs
  983. .sp 17P
  984. .ad r
  985. Blanc
  986. .ad b
  987. .RT
  988. .LP
  989. .bp
  990. .sp 2P
  991. .LP
  992. 2.3
  993.     \fIInformation flow description\fR 
  994. .sp 1P
  995. .RT
  996. .sp 1P
  997. .LP
  998. 2.3.1
  999.     \fIInformation flow diagram for successful operation\fR 
  1000. .sp 9p
  1001. .RT
  1002. .LP
  1003. .rs
  1004. .sp 33P
  1005. .ad r
  1006. \fBFigure 2\(em3/Q.83, p.  \fR 
  1007. .sp 1P
  1008. .RT
  1009. .ad b
  1010. .RT
  1011. .LP
  1012. 2.3.2\ \ \fIDefinition of individual information flows\fR 
  1013. .sp 1P
  1014. .RT
  1015. .sp 2P
  1016. .LP
  1017. 2.3.2.1\ \ \fIHold request\fR 
  1018. .sp 1P
  1019. .RT
  1020. .sp 1P
  1021. .LP
  1022. 2.3.2.1.1\ \ \fIMeaning of hold request\fR 
  1023. .sp 9p
  1024. .RT
  1025. .PP
  1026. Hold request is the information sent from FE1 to FE2 to request
  1027. that a call be placed on hold by the network.
  1028. .RT
  1029. .sp 1P
  1030. .LP
  1031. 2.3.2.1.2\ \ \fIInformation content for hold request\fR 
  1032. .sp 9p
  1033. .RT
  1034. .PP
  1035. The following information is contained in the hold
  1036. request:
  1037. .RT
  1038. .LP
  1039.     \(em
  1040.     an identifier of the call to which the hold request
  1041. applies.
  1042. .bp
  1043. .sp 2P
  1044. .LP
  1045. 2.3.2.2\ \ \fIHold confirmation\fR 
  1046. .sp 1P
  1047. .RT
  1048. .sp 1P
  1049. .LP
  1050. 2.3.2.2.1\ \ \fIMeaning of hold confirmation\fR 
  1051. .sp 9p
  1052. .RT
  1053. .PP
  1054. Hold confirmation is the information sent from FE2 to FE1 that
  1055. confirms that a call has been put on hold for the user by the network.
  1056. .RT
  1057. .sp 1P
  1058. .LP
  1059. 2.3.2.2.2\ \ \fIInformation content for hold confirmation\fR 
  1060. .sp 9p
  1061. .RT
  1062. .PP
  1063. The following information is contained in the hold
  1064. confirmation:
  1065. .RT
  1066. .LP
  1067.     \(em
  1068.     an identifier of the call to which the hold confirmation
  1069. applies.
  1070. .sp 2P
  1071. .LP
  1072. 2.3.2.3\ \ \fI(Optional) notification of hold\fR 
  1073. .sp 1P
  1074. .RT
  1075. .sp 1P
  1076. .LP
  1077. 2.3.2.3.1\ \ \fIMeaning of (optional) notification of hold\fR 
  1078. .sp 9p
  1079. .RT
  1080. .PP
  1081. (Optional) notification of hold is the information sent from FE2
  1082. towards B indicating that the call between FE1 and FE2 has been placed on
  1083. hold.
  1084. .RT
  1085. .sp 1P
  1086. .LP
  1087. 2.3.2.3.2\ \ \fIInformation content for (optional) notification of hold\fR 
  1088. .sp 9p
  1089. .RT
  1090. .PP
  1091. The following information is contained in the (optional)
  1092. notification of hold:
  1093. .RT
  1094. .LP
  1095.     \(em
  1096.     an identifier of the call to which the (optional)
  1097. notification of hold applies.
  1098. .sp 2P
  1099. .LP
  1100. 2.3.2.4\ \ \fIRetrieve request\fR 
  1101. .sp 1P
  1102. .RT
  1103. .sp 1P
  1104. .LP
  1105. 2.3.2.4.1\ \ \fIMeaning of retrieve request\fR 
  1106. .sp 9p
  1107. .RT
  1108. .PP
  1109. Retrieve request is the information sent from FE1 to FE2 to request the 
  1110. reconnection of a held call. 
  1111. .RT
  1112. .sp 1P
  1113. .LP
  1114. 2.3.2.4.2\ \ \fIInformation content for retrieve request\fR 
  1115. .sp 9p
  1116. .RT
  1117. .PP
  1118. The following information is contained in the retrieve
  1119. request:
  1120. .RT
  1121. .LP
  1122.     \(em
  1123.     an identifier of the call to which the retrieve request
  1124. applies;
  1125. .LP
  1126.     \(em
  1127.     an optional indication that:
  1128. .LP
  1129.     1)
  1130.     any channel is acceptable for retrieval, or
  1131. .LP
  1132.     2)
  1133.     a specified channel is preferred for retrieval, or
  1134. .LP
  1135.     3)
  1136.     a specified channel is exclusively required for
  1137. retrieval.
  1138. .sp 2P
  1139. .LP
  1140. 2.3.2.5\ \ \fIRetrieve confirmation\fR 
  1141. .sp 1P
  1142. .RT
  1143. .sp 1P
  1144. .LP
  1145. 2.3.2.5.1\ \ \fIMeaning of retrieve confirmation\fR 
  1146. .sp 9p
  1147. .RT
  1148. .PP
  1149. Retrieve confirmation is the information sent from FE2 to FE1 that confirms 
  1150. that communications was able to be re\(hyestablished and that the held 
  1151. call is now reconnected. If an optional indication concerning the B channel
  1152. over which communications was to have been re\(hyestablished was included 
  1153. in the retrieve request, then the retrieve confirmation serves as an acknowledgement 
  1154. that retrieval was carried out as requested. 
  1155. .RT
  1156. .sp 1P
  1157. .LP
  1158. 2.3.2.5.2\ \ \fIInformation content for retrieve confirmation\fR 
  1159. .sp 9p
  1160. .RT
  1161. .PP
  1162. The following information is contained in the retrieve
  1163. confirmation:
  1164. .RT
  1165. .LP
  1166.     \(em
  1167.     an identifier of the call to which the retrieve confirmation  applies;
  1168. .LP
  1169.     \(em
  1170.     an identifier of the channel over which the held call is
  1171. reconnected.
  1172. .sp 2P
  1173. .LP
  1174. 2.3.2.6\ \ \fI(Optional) notification of retrieval\fR 
  1175. .sp 1P
  1176. .RT
  1177. .sp 1P
  1178. .LP
  1179. 2.3.2.6.1\ \ \fIMeaning of (optional) notification of retrieval\fR 
  1180. .sp 9p
  1181. .RT
  1182. .PP
  1183. (Optional) notification of retrieval is the information sent from FE2 towards 
  1184. B indicating that the B channel between FE1 and FE2 has been 
  1185. reconnected.
  1186. .bp
  1187. .RT
  1188. .sp 1P
  1189. .LP
  1190. 2.3.2.6.2\ \ \fIInformation content for (optional) notification of retrieval\fR 
  1191. .sp 9p
  1192. .RT
  1193. .PP
  1194. The following information is included in the (optional)
  1195. notification of retrieval:
  1196. .RT
  1197. .LP
  1198.     \(em
  1199.     an identifier of the call to which the (optional)
  1200. notification of retrieval applies.
  1201. .sp 1P
  1202. .LP
  1203. 2.4
  1204.     \fIFunctional entity actions\fR \v'3p'
  1205. .sp 9p
  1206. .RT
  1207. .LP
  1208.     \(em
  1209.     201
  1210.     \(em
  1211.     Perform the holding function
  1212. .LP
  1213.     \(em
  1214.     202
  1215.     \(em
  1216.     Perform the retrieve function
  1217. .LP
  1218.     \(em
  1219.     203
  1220.     \(em
  1221.     Perform the reservation function
  1222. .LP
  1223.     \(em
  1224.     204
  1225.     \(em
  1226.     Perform the reservation management to insure
  1227. that:
  1228. .LP
  1229.      When a user (as identified by a terminal, other possibilities for further 
  1230. study) places a call on hold and reservation applies, a B channel 
  1231. should always be available on that user's interface for the user to retrieve
  1232. that call from hold; or setup, retrieve, or connect to another call. One B
  1233. channel should be kept available for the user as long as the user: (i) 
  1234. has one or more calls on hold with reservation and, (ii) is not currently 
  1235. connected to any other call. That is, the network should not reserve more 
  1236. than one B channel for a user, regardless of how a user is defined (as 
  1237. identified by a terminal, other possibilities for further study). 
  1238. .LP
  1239.     \(em
  1240.     205
  1241.     \(em
  1242.      identify the call at the FE3/FE4 interface that the optional notifications 
  1243. apply to. 
  1244. .sp 1P
  1245. .LP
  1246. 2.5
  1247.     \fISDL diagrams for functional entities\fR 
  1248. .sp 9p
  1249. .RT
  1250. .PP
  1251. The SDL diagrams for functional entities 1, 2, 3 and 4 are shown in Figures\ 
  1252. 2\(hy4/Q.83, 2\(hy5/Q.83, 2\(hy6/Q.83 and 2\(hy7/Q.83. 
  1253. .RT
  1254. .LP
  1255. .rs
  1256. .sp 29P
  1257. .ad r
  1258. Blanc
  1259. .ad b
  1260. .RT
  1261. .LP
  1262. .bp
  1263. .LP
  1264. .rs
  1265. .sp 47P
  1266. .ad r
  1267. \fBFigure 2\(hy4/Q.83 (feuillet 1 sur 2), p. 21\fR 
  1268. .sp 1P
  1269. .RT
  1270. .ad b
  1271. .RT
  1272. .LP
  1273. .bp
  1274. .LP
  1275. .rs
  1276. .sp 47P
  1277. .ad r
  1278. \fBFigure 2\(hy4/Q.83 (feuillet 2 sur 2), p. 22\fR 
  1279. .sp 1P
  1280. .RT
  1281. .ad b
  1282. .RT
  1283. .LP
  1284. .bp
  1285. .LP
  1286. .rs
  1287. .sp 47P
  1288. .ad r
  1289. \fR \fBFigure 2\(hy5/Q.83 (feuillet 1 sur 2), p. 23\fR 
  1290. .sp 1P
  1291. .RT
  1292. .ad b
  1293. .RT
  1294. .LP
  1295. .bp
  1296. .LP
  1297. .rs
  1298. .sp 47P
  1299. .ad r
  1300. \fR \fBFigure 2\(hy5/Q.83 (feuillet 2 sur 2), p. 24\fR 
  1301. .sp 1P
  1302. .RT
  1303. .ad b
  1304. .RT
  1305. .LP
  1306. .bp
  1307. .LP
  1308. .rs
  1309. .sp 22P
  1310. .ad r
  1311. \fBFigure 2\(hy6/Q.83, p. 25\fR 
  1312. .sp 1P
  1313. .RT
  1314. .ad b
  1315. .RT
  1316. .LP
  1317. .rs
  1318. .sp 24P
  1319. .ad r
  1320. \fBFigure 2\(hy7/Q.83, p. 26\fR 
  1321. .sp 1P
  1322. .RT
  1323. .ad b
  1324. .RT
  1325. .LP
  1326. .bp
  1327. .sp 1P
  1328. .LP
  1329. 2.6
  1330.     \fINetwork physical allocation scenarios\fR 
  1331. .sp 9p
  1332. .RT
  1333. .ce
  1334. \fBH.T. [T1.83]\fR 
  1335. .ps 9
  1336. .vs 11
  1337. .nr VS 11
  1338. .nr PS 9
  1339. .TS
  1340. center box;
  1341. lw(36p) | lw(12p) | lw(24p) | lw(24p) | lw(24p) | lw(12p) .
  1342. FE1    FE2    FE3    FE4        
  1343. _
  1344. .T&
  1345. lw(36p) | lw(12p) | lw(24p) | lw(24p) | lw(24p) | lw(12p) .
  1346. Scenario 1        TE    LE    LE    TE
  1347. .T&
  1348. lw(36p) | lw(12p) | lw(24p) | lw(24p) | lw(24p) | lw(12p) .
  1349. Scenario 2        TE    NT2    NT2    TE
  1350. .T&
  1351. lw(36p) | lw(12p) | lw(24p) | lw(24p) | lw(24p) | lw(12p) .
  1352. Scenario 3        TE    LE    NT2    TE
  1353. .T&
  1354. lw(36p) | lw(12p) | lw(24p) | lw(24p) | lw(24p) | lw(12p) .
  1355. Scenario 4        TE    NT2    LE    TE
  1356. .TE
  1357. .nr PS 9
  1358. .RT
  1359. .ad r
  1360. \fBTable [T1.83], p.  \fR 
  1361. .sp 1P
  1362. .RT
  1363. .ad b
  1364. .RT
  1365. .sp 2P
  1366. .LP
  1367. \fB3\fR     \fBCompletion of call to busy subscriber\fR 
  1368. .sp 1P
  1369. .RT
  1370. .PP
  1371. Under study.
  1372. .RT
  1373. .LP
  1374. .rs
  1375. .sp 37P
  1376. .sp 2P
  1377. .LP
  1378. \fBMONTAGE: RECOMMANDATION Q.85 sur le reste de cette page\fR 
  1379. .sp 1P
  1380. .RT
  1381. .LP
  1382. .bp
  1383.